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Commissioner for Patents 
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Alexandria, VA 22313 



Sir/Madam: 



Further lo Iho Notice of Appeal faxed January 21, 2005 and received in the U.S. Patent and 
Trademark Office on the same day, Appellant presents this Appeal Brief. The Notice of Appeal was 
filed following mailing of a Final Office Action on October 22, 2004. Appellant hereby appeals to the 
Board of Patent Appeals and Interferences from a final rejection of claims 1-21 in the Final Office 
Action, and respectfully requests that this appeal be considered by the Board. 



J, REAL PARTY IN INTEREST 

The subject application is owned by International Business Machines Corporation, a corporation 
having its principal place of business at New Orchard Road, Armonk, New York, 10504, as evidenced by 
the assignment recorded at Reel 011429, Frame 0838. 
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RELATED APPEALS AND INTERFERENCES 



A Notice of Appeal has been filed for the following application, which shares a common 
specification with ihe application currently on appeal. 

09/740,460 Notice of Appeal filed on or about January 1 8, 2005. 

However, because dissimilar art is cited in the present application and the above-mentioned related 
application, Appellants do not believe that the outcome of this appeal will have any bearing on the 
Board's decision on the related appeal. No other appeals or interferences arc known which would 
directly affect or be directly affected by or have a bearing on the Board's decision in this appeal, 



Claims 1-21 were originally filed m the present application. Claims 19, 20 and 21 were amended 
in a response filed July 9, 2004 to an Office Action mailed April 9, 2004. Claim 1 8 was cancelled in the 
same response. Claims 1-3, 5-7, 10-12, 14-16 and 18-21 stand finally rejected under 35 U.S.C. § 102, 
and claims 4, 8-9, 13 and 17 stand finally rejected under 35 U.S.C. § 103 7 which are the subject of this 
appeal. A copy of claims 1-17 and 19-21, as on appeal (incorporating entered amendments), is included 
in the Appendix hereto. 



No amendments to the claims have been filed subsequent to their final rejection. The Appendix 
hereto therefore reflects the current state of the claims. 



An ^affinity condition* 1 exists when a client's requests arc ail routed to the same server. Affinity 
between a particular client and server may exist, for example, during secure online transactions. This 
might be the case, for example, when a shopper is updating his shopping cart. If the shopper's cart is 
cached in a specific server, all read requests from the client may be directed to that server. Under these 
circumstances, it may be said that the user (or client) has established "affinity" with the server. If the 
designated server goes down for some reason, the user's requests may be temporarily redirected to a 
different server, breaking his affinity with the original server. When the original server is operational 
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again, affinity may be restored, A problem may arise, however, when the user resumes communication 
with the original server, since there is no way to know whether the data stored within a cache memory of 
the original server is still valid. As described in more detail below, an application developer can prevent 
this from happening by notifying the original server that affinity has been broken when it resumes 
operation. (Specification page 15, lines 4-15 and page 24, line 37 to page 25, line 19). 

Appellant's claimed invention relates to a software system, computer program product, server 
and method for detecting affinity breaks between a client and a server. (see> e.g., Specification — page 
15, lines 16-35 and page 25, line 20 to page 26, line 16). 

In some embodiments of the invention, the presently claimed software system, supporting 
client/server affinity detection, may include a server (e.g., web server 14a, FIG. 1) and a client (e.g., 
client 20a, FIG. 1), which is adapted to send requests to the server. Each "request" sent from the client to 
the server may include a unique, numeric- valued "generation ID", or G1D, More specifically, the G1D 
may represent the current state of the request, and may change each time user specific data is updated. 
(Specification - page 15, lines 16-21; and page 25, lines 20-26). 

In some cases, the presently claimed software system may include a plurality of clients, each 
adapted to send requests to the server, wherein each client has a unique "user ID". During each client 
request, the user ID of the client sending the request may be combined with the generation ID 
accompanying the request to produce an "affinity command". (Specification — page 15, lines 16-21). To 
one embodiment, the affinity command is sent from the client to the server, and returned "by the server to 
the client, in the form of a "cookie". (Specification - page 15, lines 30-35). 

When a request is received Irom a client, the server may detect an affinity break between a 
particular client (among the plurality of clients) and the server by examining the generation ID in the 
accompanying affinity command, and comparing it to an internally recorded generation ID value. An 
affinity break between the client and the server may be detected, for example, if the generation ID 
accompanying the request from the client differs from the generation ID recorded by the server. 
(Specification - page 15, lines 21-30). 
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In some cases, an affinity break may occur between a client and a server if ihc server becomes 
unavailable. When the presently claimed software system includes a plurality of servers, an affinity 
between a client and a first server may be broken as a result of the client sending a request to a second 
server. Regardless of cause, if an affinity break is detected between a client and a server, the detection 
niay be used to invalidate contents of a cache memory located within the original server. (Specification — 
page 15, lines 4-15 and lines 28-30). 

In some embodiments of the invention, the presently claimed method for delecting affinity breaks 
between a client and a server may include: (i) the client sending a request to the server, where the request 
is accompanied by a numeric-valued generation ID (GID), and (ii) the server receiving the request and 
the GJD from the client, and comparing the received GTD against a previously recorded GID. If the 
received GID matches the recorded GID, the server may increment the recorded GID and return the 
incremented GID to the client as a new GID in a third step of the method. However, if the received GID 
docs not match the recorded GID, an affinity break may be reported hetween the client and the server in a 
fourth step of the method. (Specification ~ page 15, lines 4-15 and lines 21-30). 

Tn some cases, the method may be used for detecting affinity breaks between a plurality of clients 
and a plurality of servers, each of which is equipped with a cache. Once "affinity*' is established between 
a client and a first server (i.e,, an affinity condition exists when a client's requests arc all routed to the 
same server), the affinity between the client and the first server may be broken as a result of the client 
sending a request to a second server, which may occur, e.g., if the first server becomes unavailable. 
(Specification - page 15, lines 4-15 and p4ge 25, liilC* 5-16). As iiOlvd above, an affinity break may be 

delected between a client and a server if the GID received from the client does not match the GID 
recorded in the server. In some case, an affinity break between a particular client (among the plurality of 
clients) and server may also be detected by means of the unique user ID, which is associated with the 
particular client and included, along with the generation TD, within the affinity command sent by the 
client. (Specification — page 25, line 17 to page 26, line 7). 



1, Whether claims 1-3, 5-7, 10-12, 14-16 and 18-21 are unpatentable under 35 U.S.C. § 102(c) as 
being anticipated by U.S. Patent No. 5,706,435 to Barbara et al. (hereinafter "Barbara"). 



VI. 



ISSUES 
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2. Whether claims 4, 8, 9, 1 3 and 17 are unpatentable under 35 U.S.C § 103(a) over Barbara in view 
of U.S. Patent No. 6,327,628 to Anuff et al. (hereinafter "Anuff 

VII, GROUPING OF CLAIMS 

With respect to each of the two grounds of rejection on which Appellant contests, all pending 
and rejected claims stand ov fall as a single claim group. Thus, with respect to the 35 U.S.C. § 102(e) 
rejection, rejected claims 1-3, 5-7, 10-12, 14-16, and 19-21 stand or fall as a single claim group. It is 
noted herein that dependent claim 1 8 was canceled in a previous response filed July 9, 2004 to the Office 
Action mailed April 9, 2004 and, thus, its rejection is moot. With respect to the 35 U.S.C § 103(a) 
rejection, rejected claims 4, 8, 9, 13, and 17 stand or fall as a single claim group. 

V1IL ARGUMENT 

The two issues noted above represent separate and distinct issues of patentability. In order to 
adequately address each of these issues, arguments will be lodged under separate subheadings pertinent 
to Issue 1 and Issue 2. Details as to why the rejections cannot be sustained arc believed to be clearly 
identified in the corresponding sxibhcadings. 

ISSUE 3 ARGUMENTS 

A. Patentability under 35 U.S.C IS 102(e) 

Claims 1-3, 5-7, 10-12, 14-16, and 18-21 were rejected under 35 U.S.C. §102(e) as being 
anticipated by US. Patent No. 5,706,435 to Barbara et al. (hereinafter "Barbara"). As noted above, claim 
1 8 was cancelled in a previous response, thus, rendering rejection thereto moot. As described in more 
* detail below, the § 102(e) rejection of claims 1-3, 5-7, 10-12, 14-16, and 19-21 is hereby traversed. 

The standard for "anticipation" is one of fairly strict identity, A claim is anticipated only if each 
and every element as set forth in the claim is found, either expressly or inherently described, in a single 
prior art ofrcferencc. Verdegaal Bros. v. Union Oil Co. of California, 2 USPQ2d 105U 1053 (Fed. Cir, 
1 987); MPEP 2131. Using this standard, Applicants submit the cited art fails to disclose each and every 



SN 09/740,53? Appeal Brief " p agc 5 0 f 20 

PW2 5/20 * RCVD AT 3/21/2005 4:56:10 PM [Eastern Standard Time] ' SVR;USPT0-EFXRF-1/2 1 • DfOS:8729306 * CSID:512 703 1250 ' DURATION (mnws):1 142 



MAR-21-2005 HON 04:00 PM Daffer McDaniel LLP 



FAX NO. 512 703 1250 



P. 



clement of the currently pending claims, some distinctive features of which are set forth in more detail 
below. 

1 * Independent Claims 1, l(h 19, and 21 : Barbara fails to disclose a client that sends a 
request to a server, where the request includes n numeric-valued generation ID 
(GID). 

Each of the present independent claims 1, 10, 19, and 21 set forth a communication path from a 
client to a server. Specifically, the client is claimed to send a "request" to the server. Included with that 
request is a numeric-valued generation ID, or GTD. The Specification describes the GID as a unique 
value> which is assigned to each request sent from the client to the server to represent the current state of 
ihe request (see, Specification; page 15, lines 16-21; page 25, lines 20-26). The Final Office Action 
alleges that the item "information identifying" is the same as the presently claimed GID (see, e.g., Final 
Office Action, pages 2 and 4). Appellants disagree. 

Statements in the Final Office Action suggest that "Barbara et al. In COL 2, LINES 60-65 
discloses that the server processor periodically broadcasts invalidation reports to the client processor. 
Each respective invalidation report includes information identifying which, if any, of the plurality of data 
values have been updated within a predetermined period of time before the server processor broadcasts 
the respective invalidation report [to the client]." (Final Office Action, page 2). Further statements in the 
Final Office Action suggest that "[i]t is very well known that an ID is "identifying information", which 
could come in the form of a numeric-value." (Final Office Action, page 2). As described in more detail 
below, the Appellants strongly disagree with the Examiner's contention that the "invalidation reports" of 
Barbara, or the 'information" contained therein, can be considered equivalent to the presently claimed 
requests or mimeric-valued GID. 

First ofall, Barbara clearly and repeatedly states that the "invalidation report" (and thus, the 
information contained therein) is sent or "broadcast" from a server processor to a clie nt pr ocessor (see, 
e.g., Barbara, Abstract; col. 2, lines 60-65; col. 4, lines S-26; col. 6, lines 5-40; col. 7, line 66 to col 8, 
line 26; and col 10, lines 1-22). The Examiner notes such a fact in the Office Action mailed April 9, 
2004 (e.g., Office Action page 2) and in the Final Office Action mailed October 22, 2004 (c.g,„ Final 
Office Action, page 2). Appellants assert that since the so-called "identifying information" contained 
within the "invalidation report" of Barbara is sgnLfroni a server processor — and not from a client, as 
presently claimed - the "identifying information" of Barbara cannot be included within a request sent 
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from a client, and therefore, cannot be the same as or equivalent to the presently claimed QID, which is 
sent in a request from a c lien t to a server . 

Second, Barbara fails to disclose that the invalidation reports may contain a numeric-valued 
generation 11), which is described in the present Specification as a unique value associated with each 
request sent from a client to a server to represent the current state of the request. (See, e.g., Specification, 
page 15, lines 16-21 and page 25, lines 20-26). As noted above, the Examiner suggests that "an ID is 
'identifying information', which could come in the form of a numeric-value." (Final Office Action, page 
2, emphasis added). Although this may be true, the Appellant disagrees with the liberties taken by the 
Examiner. Tnstcad of the Examiner simply making guesses based on hindsight, the burden is on the 
lixaminer to find some suggestion for the claimed limitation in the teachings of the prior art reference, 
Barbara fails to provide teaching or suggestion for a request having an ID associated therewith, and 
provides even less teaching for the presently claimed numeric-valued generation ID. 

Instead, Barbara discloses, "[c]ach invalidation report includes information identifying which of 
the data values stored in the server lOa-lOd have been updated within a predetermined interval of time" 
(Barbara, col. 4, lines 1 1-14), In various embodiments of the method, Barbara discloses that the 
"information identifying" may include: (i) a list of addresses corresponding to data updated in the server 
(jrw, e.g., Barbara, col. 6, lines 5-25), (ii) a list of addresses and time stamps for the updated data in the 
server (see t e.g., Barbara, col. 7, line 61 to col. 8, line 17), or (iii) a list of combined "signatures", or 
checksums computed over the values of data in the server (see, e.g., Barbara, col. 10, lines 1-22). 

As such, Barbara makes clear that the "information" included within the invalidation reports may 
contain a list of addresses, a Hst of addresses and timcstamps, or a list of combined signatures. 
Appellants contend that ajist of a_nv_ sort, cann ot be the same as a numeric-valued generati on 1D T which is 
described in the Specification as a unique value assigned to each request sent from a client to a server. Tn 
at least one embodiment of the method, Barbara specifically states that the "report only includes the list 
of addresses." (Barbara, col. 6, line 21, emphasis added). Therefore, even if the teachings of Barbara 
were modified to send invalidation reports from a client to a server (without sufficient motivation to do 
so), the in^aUdation reno of Barbara would still fail to include a numeri c-value d generation ID (which ' 
is unique to each request). As such, the invalidation reports of Barbara cannot be considered equivalent 
to the presently claimed requests, nor can they be considered to include the presently claimed numeric- 
valued generation TD« 
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2. Independent Claims 10, 19 and 21 : Barbara fails to disclose a server, which is 
adapted to receive the request from the client and to compare the received GID 
against a previously recorded GID. 

Each of the present independent claims 10, 19, and 21 teach that upon receiving the request from 
the client, the server may compare the received GID against a GID previously recorded within Ihc server 
to detect if an affinity break has occurred. The Final Office Action alleges that the third embodiment of 
Barbara, referred to as "Broadcasting Signatures", provides teaching for "a server that compares the GID 
received from the client against a GID that was previously recorded in the server to detect if an affinity 
break has occurred." (Final Office Action, page 3). The Appellant disagrees. 

First of all, and as noted above in Argument 1, Barbara discloses a system and method in which a 
client receives an invalidation report (an alleged "request*') from a server. However, Barbara fails to 
disclose the presently claimed system or method in which a server receives a request from a client , where 
the request includes a numeric-valued generation ID (GID), which is unique to each request and sent 
along with each request transmitted between a client and server, 

In addition to failing to receive a request and numeric-valued GID from a client, Barbara fails to 
disclose a server which functions to compare a received GID against a GID previously recorded in the 
server, The Examiner suggests that "Barbara on col 10, lines 1-7, discloses that 'Broadcasting 
Signatures' involves a comparison between,., a first set of signatures based on the contents of the server 
10a and a second set of signatures based on the contents of the cache 22 of client 20a," (Final Office 
Action* page 3). First of all, the "signatures" disclosed by Barbara are not numeric-valued generation 
IDs, or GIDs. Therefore, the signature comparison disclosed by Barbara cannot be equivalent to the 
presently claimed system and method for comparing a received GfD with a previously recorded GID. In 
addition, Barbara clearly states that the signature comparison is performed bv the client , and not by a 
server, as presently claimed. Statements in the Final Office Action even point out this fact by stating, 
"Barbara... discloses that at step 286, the client 20a compares its combined signature to the combined 
signature received in the invalidation report." (Final Office Action, page 3). For at least these reasons, 
the server processor of Barbara cannot he considered equivalent to the presently claimed server, as 
recited in claims 10, 19, and 21. 
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3. Independent Claims 1, 10, 19. and 21 : Barbara fails to disclose that, if the received 
GTD matches the recorded GID, the server increments the recorded GID and 
returns the incremented Gift to the client as a new GID. 

Each of the present independent claims 1, 10, 19, and 21 leach that, if the GID received by the 
server (from the client) matches the GID previously recorded in the server, the server will increment the 
GID and return the incremented GID to the client as a new GID. This is done to ensure that the GID 
represents the current state of the request, and may be used by the server to determine if the server has 
missed any requests sent from the client (sec, e,g., Specification, page 15, lines 21-25). The Final Office 
Action alleges that Barbara provides teaching for the present claim limitation by disclosing a method for 
comparing the combined signatures in the invalidation report with those stored in the cache memory of a 
client, and a counter which is incremented for each datum represented by the non-matching combined 
signatures (see, Final Office Action, page 2). The Appellant disagrees. 

First of all, the method steps referred to by the Examiner (e.g., stq>s 286-290, as shown in FIG. 
5B of Barbara) are only performed by the chents of Barbara (see, Barbara, col. 10, lines 23-25), and not 
be a server, as presently claimed. 

Second, Barbara fails to disclose a server, which is adapted to compare a GID received by the 
server (from a client) with a GID previously recorded in the server, and therefore, cannot provide 
teaching or suggestion for a server that performs a particular function, if the received GID matches the 
previously recorded GID. 

Third, Barbara fails to disclose that a previously recorded GID (or any GID, for that matter) may 
be incremented by the server processor (or any other computational unit within the system of Barbara) to 
foim a new GID, Instead, Barbara discloses (and the Examiner points out) that a counter may be 
incremented for each datum represented by the non-matching combined signatures (see, e.g., Barbara, 
col. 11, lines 1-10, and Final Office Action, page 2). Though Barbara discloses that a counter may be 
incremented (in step 290) to determine the "number of non-matching combined signatures associated 
with each respective datum" in the cache (see> Barbara, coL 1 1 , lines 10-15), neither the counter nor the 
value stored therein may be considered equivalent to the presently claimed Accorded GID'\ For 
example, Barbara fails to disclose that the counter value may be a unique value, which is transmitted 
along with csch request sent from a client to a server. 
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Fourth, Barbara fails to disclose that the new GID (i.e., the GID formed by incrementing the 
recorded GID) may be returned to the client. Though Barbara discloses that a counter may be 
incremented (in step 290), the incremented count value stored therein is not an incremented GTD and is 
nfii relumed to the client as a new GID. 

4. Independent Claims 1. 10. 19 and 21 : Barbara fails to disclose that an affinity 
break is detected/reported between the client and the server, if the received GID 
docs not match the recorded GID. 

F-ach of the present independent claims 1, 1 0, 19, and 21 teach that an affinity break may be 
detected (claim 1) or reported (claims 10, 19 and 21), if the GID received by the server (from the client) 
docs not match the GTD previously recorded in the server. The Final Office Action alleges that the 
"Broadcasting Signatures" method shown in FIGS. 5A and 5B of Barbara provides teaching for detecting 
or reporting an affinity break if a received GID docs not mutch a recorded GID. The Appellants disagree. 

Barbara discloses an invalidation process, which allows a client processor to invalidate select 
data values stored in the cache memory of the client, if the data values were updated in a server processor 
alYer the values were stored in the cache memory of the client (see, Barbara, Abstract). However, 
Barbara fails to disclose that an affinity break may be detected or reported between a client and a server, 
i f a received GID (from the client) docs not match a recorded GID (in the server). In fact, Barbara has 
absolutely nothing to do with detecting or reporting affinity breaks between a client and a server, 
regardless oTlhc manner in which detection is performed. 

In light of the Examiner's suggestions in the Final Office Action* it appears that the Examiner 
docs not understand the difference between an "affinity break," as set forth in the present claims, and 
invalidation" in general. Details of what would constitute an affinity break and the differences between 
client/server affinity and cache incohcrcncy/invalidation are set forth throughout the present specification 
(see, e.g., Specification, page 15, lines 4-35; page 24, line 37 to page 26, line 7). In general, affinity 
breaks are provided to determine whether communication between a particular client and a particular 
server has been interrupted. If communication has been interrupted, the client data stored in the cache 
memory of a server may be invalid. To determine if an affinity break has occurred, a GID can be used 
that is unique to each request sent from the client to the server. The GID sent from die client can be 
compared with a stored GID to determine if a break has occurred. As each request is received, the server 
will increment its GID and a break is encountered if the received and stored GIDs (as incremented) do 
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not match. Comparing GIDs and detecting affinity breaks occurs well before any determination is 
needed on which pieces of data stored in cache should be invalidated. 

Barbara only deals with instances in which invalid data are known and a report of such data (i.e., 
an invalidation report) is present. Tins is entirely non-analogous to affinity breaks, or the problem solved 
by the present claims of determining a break in communication between a client and a server. Certainly, 
a skilled artisan would appreciate the difference between detecting communication breaks between a 
particular client and server (which are detected as affinity breaks) and sending invalidation reports to a 
client (possibly, after an affinity break has occurred) to allow the client to update data stored therein. 

In other words, though the presently claimed method for detecting an affinity break may 
ultimately be used for invalidating contents (in the server), it is unreasonable for one skilled in the art to 
assume that, because Barbara discloses an invalidation process, the teachings of Barbara must inherently 
disclose a preceding process, which determines whether or not an affinity break has occurred between a 
client and a server. Barbara simply fails to disclose any process for detecting if an affinity break has 
occurred, and therefore, cannot teach or suggest that an affinity break may be detected (or reported) if a 
G1D received (from the client) docs not match a GID previously recorded in the server, as presently 
claimed. 

Conclusion 

As explained in Arguments 1-4 above, Barbara fails to anticipate not just one, but substantially 
all limitations recited in claims 1, 10, 19 and 21. Since claims 2, 3, 5-7, 11, 12, 14-16 and 20 are 
dependent from claims 1, 10 and 19, claims 2, 3, 5-7, 11, 12, 14-16 and 20 arc also not anticipated by the 
cited art. Accordingly, Appellants assert that an anticipatory rejection of the current claims cannot be 
sustained and, therefore, request that this rejection be reversed, 
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ISSUE 2 ARGUMENTS 

A. Patentability under 35 U,S.C S 103fa) 

Claims 4, 8, 9, 13, and 17 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Barbara in view of U.S. Patent No. 6,327,628 to Anuff et al. (hereinafter "AnufF)- Because claims 4, 8, 
9 % 13 and 17 arc dependent from independent claims 1 and 10, the arguments presented above for 
patentability of claims 1 and 10 apply equally to claims 4, 8, 9, 13 and 17, and are herein incorporated by 
reference. In addition to the 35 U.S.C. §102 arguments presented above with respect to claims 1 and 10, 
arguments arc provided below to establish patentability of the current claims under 35 U.S.C. § 103(a), - 

MPEl' 2143 establishes the basic requirements in finding a prima facie case of obviousness. As 
described, to establish a case of prima facie obviousness of a claimed invention, three criteria must be 
met. First, there must be some suggestion or motivation, either m the references themselves or in the 
knowledge generally available to one of ordinary skill in the art to modify the references or to combine 
reference teachings. Second, there must be a reasonable expectation of success. Finally, the prior art 
references must Leach or suggest all the claim limitations. Specifically, "all words in a claim must be 
considered when judging the patentability of that claim against the prior art." In re Wilson 424 F.2d. 
3 382, 1385 (CCrA 1970). If an independent claim is nonobvious under 35 U.S.C. 103, then any claim 
depending therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). 

1, None of the cited art teaches or suggests a server adapted to: (i) receive a request 
including a numeric-valued generation ID (GID) from a client, (H) compare the 
received GID against a GID previously recorded in the server, (iii) increment fhc 
recorded GID and return the incremented GID to the client as a new CID, if the 
received GID matches the recorded GID, or (iv) report an affinity break between 
the client and the server, if the received GID does not match the recorded Gtt>. 

For at least the reasons set forth above in the Issue I arguments, Barbara fails to provide leaching 
or suggestion for a server, as recited in present claims 1 and 10. Even though Anuflf is not cited against 
present claims 1 and 10, Appellants assert that the teachings of Anuff cannot be combined with those of 
Barbara to overcome the deficiencies therein. 
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Anaff discloses n portal server that presents an HTML page with a plurality of modules that are 
formatted in a predetermined layout (Anuff, Abstract). However, Anuff fails to disclose that the portal 
server (or any other server for that matter) may be adapted to: (i) receive a request including a numeric- 
valued generation ID (GID) from a client, (ii) compare the received GID against a GID previously 
recorded in the server, (iii) increment the recorded GID and return the incremented GID to the client as a 
new GID, if the received GID matches the recorded GID, or (iv) report an affinity break between the 
client and the server, if the received GJD does not match the recorded GID, In other words, like Barbara, 
Anuff fails to disclose any of the limitations recited in claims 1 and 10. 

Since Anuff fails to disclose the above-mentioned claim limitations, which arc also absent from 
the teachings of Barbara, the teachings of Barbara and Anuff cannot be combined in a manner that would 
disclose nil limitations recited in claims I and 10. In addition, Barbara and Anuff cannot be modifi ed to 
teach or suggest the above-mentioned claim limitations, since neither Barbara nor Anuff provide 
teaching, suggestion or motivation to do so* Obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so. In reFine, 837 F,2d 1071, 5 USPQ2d 1596 (Fed.Cir, 1988); In re 
Jones, 958 R2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992); MPEF 2143.01, 

2. None of the cited art provides teaching or suggestion for a server adapted to 

• perform the functions noted above and recited in claims 1 and 10, where the server 
comprises a Java Virtual Machine (JVM) equipped with a cache. 

Claim 4, which includes all limitations recited in claim 1, places a further limitation on the 
presently claimed server to comprise a Java Virtual Machine (JVM) equipped with a cache. Statements 
in the Final Office Action admit that Barbara does "not explicitly disclose a Java Virtual Machine (JVM) 
equipped with a cache,'* but suggests that Anuff discloses "a method where a memory cache can be 
cleared by the Java Virtual Machine (JVM) when resources are running low." (Final Office Action, page 
7). Therefore, the Examiner suggests that it would be "obvious to one of ordinary skills in the art at the 
time the invention was made to incorporate Barbara's teaching of coherency in cache memory with [a] 
portal server using JVM [as] disclosed by Anuff because an improved method for maintaining a coherent 
view of the data in the cache of each mobile unit is desired." (Final Office Action, pages 7-8). As 
described below, the Appellants disagree that the combined teachings of Barbara and Anuff could 
somehow be interpreted to read upon the presently claimed server. 
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As noted above in Argument 1, Barbara and Anuff each fail to provide teaching or suggestion for 
a server that performs the functionality recited in claims 1 and 10. The Examiner admits that no teaching 
or suggestion can be found within Barbara for a $erver that includes a JVM equipped with a cache. 
Though Anuff may briefly mention that a "memory cache can be cleared by the Java Virtual Machine 
(JVM) when resources are running low" (AnuIT, col. 1 1 , lines 61-63), the point is moot. Even if the 
porlal server of Anuff (which may include a JVM) is combined with the teachings of Barbara (without 
sufficient motivation to do so), the combined teachings of Barbara and Anuff would still fail lo disclose a 
server that performs the functionality recited in claims 1 and 10. Therefore, the combined teachings of 
Barbara and Anuff fail to disclose all limitations of dependent claim 4, 

3. None of the cited art provides teaching or suggestion for a system (or method) in 
which a server is adapted to perform the fractions noted above and recited in 
claims 1 and 10, lyhcrc the system comprises an object-oriented software system. 

Claims 9 and 13, which include all limitations recited in claims 1 and 10, place a further 
limitation on the presently claimed system and method by reciting that the system comprises an object- 
oriented software system. Statements in the Final Office Action suggest that teaching for an object 
oriented software system may bo found in column 4, lines 47-48 of Anuff (see, Final Office Action, page 
8), Though Anuff docs mention that an "object-oriented software system consists of software objects", 
Anuff docs not disclose an object-oriented software system (or method), which includes a server adapted 
to perform the functions recited in claims 1 and 10. Since Barbara also fails to disclose such a server, the 
combined teachings of Barbara and Anuff cannot be relied upon to provide teaching or suggestion for aj| 
limitations recited in claims 9 and 13, which include the limitations recited in base claims 1 and 10. 

4. None of the cited art provides teaching or suggestion for an affinity command that 
may be sent by a server to a client (and returned by the client to the server) in the*, 
form of a cookie. 

Claims 8 and 17 each recite an additional limitation that states an "affinity command is sent by 
the server to the client and returned by the client to the server in a cookie." Statements in the Final 
Office Action suggest that the login information disclosed by Anuff "can be stored as a browser cookie 
so that users don't have to log in each time they visit a site" (Final Office Action, page 8). As such, the 
Examiner appears to suggest that the "login information" of Anuff is somehow equivalent to the 
presently claimed affinity command. The Appellants disagree. 
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In column 1 3, lines 25-31, Anuff discloses a "login page [that] enables users to identify 
themselves to ihc portal server by entering their user name and password. The login information can be 
stored as a browser cookie so that users don't have to log in each time Ihcy visit a site*** Though Anuff 
mentions the use of a cookie, the login information stored in Ihc cookie of Anuff (i.e., a user name and 
password) cannot be considered equivalent to an affinity command, which is described in the present 
claimed case as including a user ID and a generation ID, where the user ID is unique to each client and 
the generation ID is unique to each request sent from a client to a server (see, e.g., present claims 3 and 
12; Specification, page 15, lines 16-21). Therefore, Appellants assert that Anuff fails to disclose the 
limitations recited in claims 8 and 17. 

Conclusion 

For the foregoing reasons, Appellant asserts that independent claims 1 and 10, as well as claims 
dependent therefrom* are patcntably distinct over Barbara and Anuff. Contrary to the characterizations 
made in the various Office Actions, the cited references cannot be properly combined or modified to 
provide teaching for all limitations recited in claims 4, 8, 9, 13, and 17> especially since those claims 
include all limitations of base claims 1 and 10. Accordingly, Appellants assert thai a prima facie case of 
obviousness has not been duly set out and, therefore, request that this rejection be reversed. 

IX. CONCLUSION 

For the foregoing reasons, it is submitted that the Examiner's rejection of claims 1-21 was 
erroneous, and reversal of the decision is respectfully requested. 

Tho Commissioner is authorized to charge the required fees to Daffer McDaniel LLP deposit 
account number 50-3268/5468-05700. 
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APPENDIX 



The present claims on appeal arc as follows. 



I. 



A software system for distributed web applications, supporting client/server affinity detection, 



comprising: 



a server; 

a client, adapted to send requests to the server; and 

a numeric-valued generation ID, accompanying each request from the client to the server, 
incremented by the server upon receiving the request, and recorded by the server before 
being returned to the client, and such that if the generation ID accompanying a request 
from the client differs from the generation ID recorded by the server, an affinity break 
between the client and the server is delected. 

2. The software system as recited in claim 1, further comprising a plurality of clients adapted to 
send requests to the server, wherein each client has a unique user ID. 

3. The software system as recited in claim 2, further comprising an affinity command, which 
combines the generation ID accompanying a request with the user ID of the client sending the request, 
and by means of which the server may detect an affinity break with a particular client among the plurality 
of clients. 

4. The software system as recited in claim 3, wherein the server comprises a Java Virtual Machine 
(JVM) equipped with a cache. 

5. The software system as recited in claim 4, further comprising a plurality of servers, wherein 
affinity between a client and first server may be broken as a result of the client sending a request to a 
second server, 

6. The software system as recited in claim 4, wherein an affinity break between a client and a server 
may occur if the server becomes unavailable. 
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7. The software system as recited in claim 4 7 wherein detection of mi affinity break between a client 
and a server may be used to invalidate contents of the cache in the server, 

8. The software system as recited m claim 4, wherein the affinity command is sent by the server to 
the client and returned by the client to the server in a cookie. 

9. The software system as recited in claim 1, further comprising an object-oriented software system. 

10. A method for detecting affinity breaks between a client and a server equipped with a cache in a 
software system for distributed web applications, comprising: 

the client sending a request to the server, accompanied by a numeric-valued generation ID (GID); 

the server receiving the request and the GTD from the client, and comparing the received GID 
against a previously recorded GID; 

if the received GID matches the recorded GID, incrementing the recorded GID, and returning it 
to the client as the new GID; and 

if the received GID does not match the recorded GID, reporting an affinity break between the 
client and the server. 

11. The method as recited in claim 10, further comprising detecting affinity breaks between a 
plurality of clients and a server, wherein each client has a unique user ID. 

12. The method as recited in claim 11, further comprising sending an affinity command with each 
request from a client, such that the affinity command combines the GID with the user JD of the client 
sending the request, and detecting an affinity break with a particular client among the plurality of clients 
by means of ihc user ID. 

13. The method as recited in claim 11, wherein the software system comprises an object-oriented 
software syslcm. 
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14. The method as recited in claim 12, further comprising detecting affinity breaks between a 
plurality of clients and a plurality of servers, each of which is equipped with a cache, such that affinity 
between a client and first server may be broken as a result of the client sending a request to a second 
server. 

15. The method as recited in claim 14, wherein an affinity break between a client and a server may 
occur if the server becomes unavailable, 

1 6. The method as recited in claim 15, wherein detection of an affinity break between a client and a 
server may be used to invalidate contents of the cache in the server. 

17. The method as recited in claim 16, wherein the affinity command is sent by the server to the 
client and returned by the client to the server in a cookie. 

1 9. A computer program product in a computer readable medium for use in detecting affinity breaks 
between a client and a server, the computer program product comprising: 

instructions for the server receiving a request and a numeric-valued generation ID (GID) from the 
client, and comparing the received GID against a previously recorded GTO; 

instructions for incrementing the recorded GID, and returning it to the client as the new GID, if 
the received GID matches the recorded GID; and 

instructions for reporting an affinity break between the client and the server, if the received GID 
does not match the recorded GID, 

20. The product as recited in claim 19 further comprising: 

instructions for the client sending a request to the server, accompanied by a numeric-valued 
generation ID (GID). 
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21 . A server including memory and processor detecting affinity breaks, comprising: 

means for the server receiving a request and a numeric-valued generation ID (GTD) from the 
client; 

comparing the received GID against a previously recorded GID; 

means for incrementing the recorded GID, and returning it to the client as the new GlD, if the 
received GID matches the recorded GID; and 

means for reporting an affinity break between the client and the server, if the received GID does 
not match the recorded GID. 
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